-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📖 add a note to check with maintainers for blocked comms emails #8819
Conversation
/lgtm |
LGTM label has been added. Git tree hash: 231950ff9636aec3dcf908efd4350416abbf9ef4
|
docs/release/release-tasks.md
Outdated
@@ -367,6 +367,7 @@ upcoming code freezes etc based on the [release timeline (1.4 example)](./releas | |||
|
|||
Information can be distributed via: | |||
* `sig-cluster-lifecycle` mailing list | |||
* Note: Ensure that the communication email was received by the community. If unsure, check with the maintainers if the email was pending for approval and needs to be unblocked. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think only sig cluster lifecycle leadership has the rights.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
confirmed, only a few sig leaders can do this operation (access rights for mailing lists are tricky, I know there was some work in progress but I'm not really up to date)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some notes:
- AFAIK all the messages from non-members are moderated (so please send the message from members email address)
- It should be possible to set up all the comm team members as enabled to post at the beginning of each release cycle, but we should investigate this a little bit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I am a little confused and to clarify, do non-members are folks who are not part of
Kubernetes_sigs
org? Because I am part of Kubernetes-sigs org and yet my email was not delivered to the mailing list on first attempt. One of the sig leaders had to intervene and "approve"(I guess) the email.
It should be possible to set up all the comm team members as enabled to post at the beginning of each release cycle, but we should investigate this a little bit.
I can help in investigating this. Who do I reach out to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per our understanding folks have to be just members of the mailing list. I would keep this simple and just say whoever wants to send mails should join the mailing list before.
Then they can send mails, and if they see that the mail doesn't show up on the mailing list they can ask sig leadership / Fabrizio to check if the mail has to be approved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
member in this case means subscribed at the mailing list, sorry for the confusion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me. Updated.
a17d3e0
to
a8ad1c6
Compare
docs/release/release-tasks.md
Outdated
@@ -82,9 +82,10 @@ As of now we ask for volunteers in Slack and office hours. | |||
|
|||
#### Finalize release schedule and team | |||
|
|||
1. Finalize release schedule and team in `release-1.4.md`. | |||
1. Finalize release schedule and team in `release-x.y.md`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind but just fyi "* The examples in this document are based on the v1.4 release cycle."
The idea was to have concrete examples to make everything easier to understand.
I"m fine either way, but we should probably be consistent and either use a concrete example or use x.y, x.y+1, x.y-1 etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me. Updated.
docs/release/release-tasks.md
Outdated
@@ -367,6 +367,7 @@ upcoming code freezes etc based on the [release timeline (1.4 example)](./releas | |||
|
|||
Information can be distributed via: | |||
* `sig-cluster-lifecycle` mailing list | |||
* Note: Ensure that the communication email was received by the community. If unsure, check with the maintainers if the email was pending for approval and needs to be unblocked. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per our understanding folks have to be just members of the mailing list. I would keep this simple and just say whoever wants to send mails should join the mailing list before.
Then they can send mails, and if they see that the mail doesn't show up on the mailing list they can ask sig leadership / Fabrizio to check if the mail has to be approved
a8ad1c6
to
059dc69
Compare
Let's go ahead with this one /lgtm |
LGTM label has been added. Git tree hash: 5a8cd5210c9fd3b1f6fb9e38df271c403d9bad63
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
mailing-list
step of#### Continuously: Communicate key dates to the community
task.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):